Waiting for master to be fixed before I push deprecation fix :)

@iltar

I am inclined to agree, but after more refactoring efforts elsewhere I ran into a possible issue with the anon sorting position:

Enabling anon as possible position means that you can use a custom AnonymousListener. Nothing wrong with that, IMHO, but the literal key anonymous (which is now reserved for the bundled listener) is used to search the array of listeners keys in FirewallConfig to determine allowsAnonymous().

Which begs the question: should the position of a listener as returned by a factory be interpret as the type of a listener? I don't think this is the case for pre_auth, especially not in the way guard uses it.

So maybe a sorting position with a different semantic value would make more sense.

What's the status of this PR?

@fabpot

1. There doesn't seem to be any support for adding a "post_authentication" listening position. @iltar seems to think I am trying to solve a problem that doesn't exist and by doing so am inviting improper use of firewall listeners (which I don't agree with, but there doesn't seem to be much point in further debating the issue)

2. There was support for the refactoring I did (extracting the anonymous listener), but in doing so I discovered that the semantic value of "listener positions" is confused: being used as "type" in FirewallConfig::allowsAnonymous() and perhaps elsewhere. This reduces the value of the refactoring to a point where, considering the general lack of interest in refactoring the security component, it is not worth the trouble.

Unless any of this has changed, this should be closed (#22260 too).

Thank you @kleijnweb for the quick and honest feedback. I really appreciate it. I'm going to trust @iltar judgement on this one and close.